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ABSTRACT 



This study investigates the management of computer centers, with emphasis 
on managing the programming effort. Problems and objectives of programming 
management are examined and techniques used in selected business and governmental 
organizations are presented. 

The data were collected by the case study method by surveying seven organi- 
zations . The particular aspects of the problem discussed in this report emphasize 
programming objectives and standards. 

This report is supplemented by the documentation of its case studies pub- 
lished in a separate volume (Gerald W. Gill and Alton P. Jensen, "Management of 
Computer Programming. Part II: Case Studies", Atlanta, Georgia, Georgia Institute 
of Technology, Jan. 1969). 




INTRODUCTION 



Since the computer became commonplace in industrial, governmental and pub- 
lic utility applications , technological change in hardware and software has outpaced 
the ’’humanware” required to control the machines and the specialists who make them 
work. Change has been rapid and continuous. The result has been a loss of control 
by management in the presence of unprecedented success. 

The acute problems of manning the programming effort have been recognized 
since the middle of the last decade. But, because of the constant upward expansion of 
equipment and applications , managers have been too busy to think much about program- 
ming management. 

In the early sixties, problems became so acute that management’s attention was 
forced to the issue. Personnel problems include recruiting, training, evaluating and 
keeping qualified programmers. The programmer market is highly competitive and 
mobile. At any given time there are 50,000 more jobs than programmers. 

Control problems include rating and controlling oerformance of programmers. 
Closely associated are the problems of program maintenance and protection against 
indispensable programmers. 

The objective of ’’programming management” must be to organize the effort 
and establish personnel policies and standards to control methods and performance 
in order to solve these problems and effectively meet programming requirements. 

This study has investigated the management of computer centers with emphasis 
on managing the programming effort. The report examines problems and objectives 
of programming management, and it presents techniques used in various business and 
governmental organizations. 
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PROBLEM AREAS IN PROGRAMMING MANAGEMENT 



Organization of Computer Centers 

Although it is popular to state that the computer system must be an independ- 
ent department headed by a manager experienced in EDP, other arrangements can be 
successful. Other viewpoints hold that the computer should be under the department 
which will use it most or within the one with the highest clerical costs. 

The manager of an MIS, data processing department or EDP department vdll 
find this decision alreacfy made for him. The point is, however, that as needs and 
applications change the organization will need revising. 

In this particular investigation, EDP managers’ backgrounds varied from a 
lawyer to an accountant. This is not to discount the advisability of an appropriate 
background. The real lesson is that organization and management are variable from 
company to company and from individual to individual. 

To establish some common ground, the following organization chart is pre- 
sented. It is not offered as correct or as a recommended structure, but as one basic 
grouping of tasks necessary to most computer centers. The functions are not dis- 
cussed at this time as seven particular organizations will be examined later. 

Basic to the purposes of this report are the decisions as to how programmers 
are organized. Programmers and ^sterns Analysts can be separated or one group. 
Programmers may be organized as a team or as functional groups. Also important 
is how the organization provides for control. 

Personnel 

Recnutu^. The soaring cost of programming, delays in job completion and 
debugging, and the cost of replacing programmers, demands more than Parkinson’s 
’’Reject everyone over 50, under 20 and anyone called Murphy." 

Sources include other company’s programmers, employees of your own organi- 
zation, inexperienced but schooled graduates of recognized universities, technical 
schools, business schools and programming institutes. 



MANAGER 




. Fig. 1. A Sample Organization Chart for a Computer Center 
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Screening is usually by applici>* on, interview and testing. Many tests are avail- 
able. The most popular is the EDPM aptitude test prepared by the Psychological Cor- 
poration in 1955, which is usually called the IBM PAT. Some controvert exists over 
the fact that this test is timed. Brandon Enterprises offers an aptitude test de-empha- 
sizing speed. 

2. Training. This varies, of course, with the experience of the trainee. All 
manufacturers provide a wide variety of instmictional programs both formally and in- 
formally. Frequently such courses are administered parallel to on-the-job training. 

3. Retaining . The tendency has been to compete financially with other com- 
panies to retain valuable programmers by outbidding competitors. There are several 
dangers in such practices . Other factors affecting retention are advancement oppor- 
tunity, (e.g., operator - programmer - systems analysts - manager) challenging work, 
loyalty, pleasant working situation and personal relations. 

4. Evaluating . This has to be largely subjective for programmers. Close ob- 
servation helps. You can watch a programmer, but perhaps more can also be learned 
by watching his associates work with him. Observable rating factors include; 

— Viewpoint (systems or narrow) 

— Promotability 

— Loyalty 

— Proper documentation 

— Test routines and debugging 

— Meeting of reasonable deadlines. 

Control vs. Change 

Management must protect itself against errors, problems of personnel turnover, 
indispensable programmers and fraud or sabotage. This calls for control over infor- 
mation and control over people. Brandon distinguishes between control over perform- 
ance and control over methods, prescribing s tandards as the first step toward achiev- 
ing management control. 

Few things are as prone to change as information systems. Change introduces 
disorder and can cause loss of control. An information system evolves and with every 
change it evolves more and faster irreversibly. Just as a home run cannot be undone 
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in a. ba.ll game, once a system changes, the job, people and environment are changed 
forever. 

Control costs money. Therefore, a basic question is: how much control is 
required? Some elements of control are educational and psychological. However, 
in modem computer uses, measurable techniques must be employed when possible. 
Scientific methods are available . Such methods are not used as effectively or as 
extensively as they could be. 

The goal cannot be to maintain the ’’status quo”. Managers must retain the 
control necessary to direct away from confusion and destruction toward a state of 
order which will survive change. An example of this kind of thinking would be the 
attitude that a program begins when it goes on the air. 

A few comments are given on the subject of controls. 

— Control methods must assure the security and quality of information 
processing. 

The best controls are active and prevent errors from entering the 
system to e^lode throughout. 

The tendency is to overcontrol or not control at all. 

— Controls should be used with moderation. 

— Statistics should be kept and monitored. 

— A separate group of people must exist within the organization 
to establish and administer control. 
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OBJECTIVES AND STANDARDS 



IL 



unwiuw i , 



Objectives 

Now that the problems have been discussed the objective will be expanded to 
include establishing and maintaining— 

1. The organizational structure and job definitions to minimize duplication 
of effort and maximize effectiveness. 

2. Personnel policies that wdl successfully locate, train, evaluate, retain 
and control qualified programmers . 

3. Control and protection against error and change. 

4. Efficient methods of scheduling and forecasting programming projects. 

5. Effective program maintenance. 

6. Constant review of progress and a flexibility which will prevent loss 
of control with future changes . 

Brandon e^lains that installation of ADP equipment is the most technical task 
management has ever faced. As a result, there has been little organization or con- 
trol applied. Thus we have a self-perpetuating condition of questionable efficiency 
and economy. 

Hopefully the methods of programming management should reduce costly 
programming waste, personnel turnover and ineffectual performance on equipment. 

There are tools for these objectives, but first a caution that a tool can be bad, 
good or improperly used. For instance, a b^ standard might add time and expense 
instead of helping. 

Standards 

Standards and Management . Planning and control are difficult in this infant 
field. A case can be built against the use of standards, but most managers deem them 
necessary as the medium for management control. Methods standards and perform- 
ance standards are linked through documentation. 

A common problem is that everyone believes in standards — for others. A 
frequent complaint is that standards restrict creativity and increase workloads. But 
Brandon dismisses this as a myth. 
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On the other hand there is little doubt that the use of good standards aids plan- 
ning, increases control, enables management to measure and predict performance, 
simplifies training, improves communication and eases conversions. 

Standards must have the support of top management and must be based upon 
experience. The objective must be practicability and not just a requirement for 
’’paperwork", m the form of job descriptions and terminology, standards should mini- 
mize confusion. In the form of work documentation and program documentation, good 
standards improve communications. 

Performance standards should improve management's ability to evaluate and 
predict. If good standards exist, planning for programming can be improved. Records 
can be kept and analyzed to enable consideration of the complexity of the job, experi- 
mce of programmer, similarity to previous programs, program language to be used, 
standard routines available, etc. These records must be further refined by adding 
time taken for training courses, other duties, illness and vacation. Surely the guess- 
work will be less haphazard if these areas are standardized to allow estimates for 

such factors. 

The prime question for management is whether standards can be enforced. 

This involves personalities, attitudes and management techniques. The end result 
must be an adjusting of the level of detail to a reasonable level which is to be strictly 

enforced. 

2. Standards and Programmers . The tendency among programmers is to 
resist being pinned down with detailed job specifications. As programming progresses, 
ways are usually discovered to save time, save space, or just be more sophisticated. 

A dictionary definition reflects that standards are "authoritative models or 
measures, or patterns for guidance taken by general consent as a basis of comparison." 
This implies that without "general consent" you have no stand a r ds. Thus it is import- 
ant to communicate the need for standards to programmers and to involve them in 

creating and updating standards. 

For example, a standard method of programming and documenting should make 
program maintenance and reprogramming for conversions easier. This should be a 
selling point to programmers. Furthermore , standards should mean that when a pro- 
gram is finished the programmer will not be continually questioned by operators, 
supervisors, users and librarians. 
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When large programs are created in modules and tested individually, standard 
structures are the only suitable means of communications between various program- 
mers. Files and tape libraries must be indexed, cross referenced and made available 

to programmers . 

Any work is simplified if it is clearly defined and nothing is worse than not 
knowing exactly what is expected. Thus standard formats, preferred practices, mean- 
ingful names and symbols and a definite reference for questions concerning these prac- 
tices can become pleasant for all concem.ed, 

3. Rtaudarda. There is a need for comprehensive national standards 

in some programming areas. Few exist! Nor can more be expected in the near future. 

Standards differ with machines, types of machines, manufacturer, mdustry, user and 
The result is that each department must standardize within. 

Meanwhile, government organizations such as ASA and ISO and trade organiza- 
tions such as ACM and DPMA continue to try. The number me offenders are the 
manufacturers who change terminology with changes in technology. 

4. Standards . Certain standards are inherited. That is, stand- 
ards are imposed by the computer or by the language used. Kven if standards are 
accepted, they must be communicated. Manufacturers' manuals outline the hardware 

and language limitations. 

But, within each organization, standard procedures must be in writing and en- 
forced. This must include specifications, progress and costs reporting, formal change 
procedures, good programming practices and documentation. Documentation refers to 
clearly outlined work stotements, system design, program design, data descriptions 
and testing results. But standards themselves must be documented. The most import- 
ant instrument for this is usually called the "Standards Manual". 

The Standards Manual 

Initially it must be decided whether this is to be a reference or a working manual. 
It is doubtful that it can be both. Also, there is no need to compete with the manufacturer 

by diq>licatlng porticms of his manuals on hardware or language. 

This manual should be readily available and easy to use. Some simple prescribed 
method of indexing and posting changes is required. A beautiful book adds decor but 
little else if it is difacult to use. People trust their memory rather than to look up 
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the detaUs One popular fonnat is a loose-leaf binder ,vlth various sections as needed 
revzsion log reflecting replaced pages and dates simplifies the job of keeping the 
manua current. Each manual should have one person responsible for its currency 
This manual should be kept as brief as possible. For instence if there are “ 
subroutmes to describe, this might make the book so thick that it would be fright- 

IT! f • ““““ separately for reference leaving a thinner and 

more friendly looking manual, 

short, zt should be written to express Instead of to impress ! 

Each manufacturer wifl provide assistance in establishing a standards manual 
e^ple, IBM provides a manual C20-1670-0. Management Planning Guide for a 
W of Date Process aan^ This manual is comprehensive yet deteil^m^d 

rd^rse™ - “ 

I Systems Analysis 
n Systems Documentation 
m I^ogram Documentation 

IV Production Run Procedures 

V Controls 

VI Standard Macros 

Vn structure and Rmoticms within Department 
VIH Miscellaneous 
IX Revision Log 

Documentation 

Documentations should include description of data elements, layouts, file specifi- 
cations and applications descriptions by sys^. A documentation dossier for each pro- 

P gr flow chart, a narrative explanation, layouts, run procedures, a Usting with 
sample data and a complete record of revisions. 



Documentation also includes the use of standard forms, decision tables, codes, 
operating dossiers, and schedules. To repeat a previous statement, the standards 
manual itself is a document describing required procedures. 

Controls 

All cards, tapes, disk files, dossiers, forms, handbooks, manuals, and pro- 
grams must be logged, coded, filed, indexed, backed-up, safeguarded and revised. 
Schedules must be created and maintained. Networks such as PERT and GANT charts 
promise some help in scheduling, 

A particular weakness is in systems analysis and problem specification to pro- 
grammers. Problems, programs, and people are hard to time or evaluate. Rating 
performance is basically a matter of experience. Speed is not the only factor in pro- 
gramming as run time, memory space, maintainability, documentation, and team work 
are other factors. Standard forms and documents increase control in this respect. 
Program documentation packages, production packages, systems packages and program 
specifications strengthen control over both methods and performances. Thus documen- 
tation should be modeled as a data bank and provide control for the analysis, program- 
ming and production stages, 

A good practice is to employ at least two programmers on any job, preferably 
all the way through testing. This should optimize techniques, educate all members of 
the team and minimize errors. Also, with more people familiar with the program, 
there is some protection against programmer turnover problems. 

It can be difficult to control programmers if they work in one big group physically 
located in one large room. Private offices seem to be preferred, but are too expensive. 
The common physical arrangement is two programmers per office. 





CURRENT STATUS OF PROGRAMMING MANAGEMENT 



The results of this study are based on a survey of seven organizations « Actual 
survey data are published in a complementary, separate report (G. W, Gill and A, P . 
Jensen, "Management of Computer Programming. Part 11: Case Studies," Atlanta, 

Ga. , Georgia Institute of Technology, Jan. 1969). 

The seven participating organizations represented the following areas and 
operated the equipment indicated: 

1. A Public Utility Company; IBM 360/40 with IBM 1287 Optical 
Scanner and Data Cell 

2. A Manufacturing and Distribution Company; IBM 360/65 with 
Disk and Associated Communications Equipment 

3. A Local Government Agency; IBM 360/30, 20 

4. A Heavy Manufacturing Company; IBM 360/30 and a special 
purpose process control computer 

5. An Aerospace Contracting Company ;IBM 360/50, 30 with a 
Philco 6000 Multi- Font Print Reader and a wide range infor- 
mation processing devices. 

6. A Large Federal Government Agency;UNIV AC 1108’s, IBM 
7094’ s, 360 ’s, etc. 

7. A Software Contracting and Consulting Company; no equipment 
in house. 

Findings of the Survey 

The following is a summary of the state of the art of managing the programming 
effort, as determined by the survey. 

1. The structural trend is to locate the computer within a separate staff re- 
porting directly to the president of the organization. 

2. Little uniformity is found in programmer organization, except that no 
company divided its programmers into groups such as flow charters and coders . 
Further there is no trend toward separate program maintenance groups. 
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3. All companies are pleased with the support given by manufacturers — no^^'. 
There have been past problems and two managers expressed mild displeasure concern- 
ing software. 

4. All organizations were familiar with the problems investigated — many by 
first-hand experience. Most have learned that one failure is not terminal. 

5. Indications are that, although the demand still exceeds the supply of pro- 
grammers, the prime targets are now inexperienced persons from within and new 
graduates of respected schools. Two years experience is no longer a prerequisite. 

6. Training is done on the job and is supplemented by the training programs 
of manufacturers. 

7. Conversion of equipment, software and applications is the normal state of 

affairs. 

8. Changes are usually under intense pressure which often relegate standards 
and documentation to low priorities. All managers have standards and require docu- 
mentation. A definite gap exists between desires and practices. 

9. No results are evident from efforts of national standards associations. 

No standard language is in sight. (There was one dissenting opinion on PL/l.) There 
is little hope for compatability between machines, languages and programs - - soon. 
Everyone is resigned to live forever with non-standard terminology. Not one glossary 
was found at any level. 

10 . Standards and control for systems analysis and problem specification are 
weak to non-existent. Prc^ramming could be described as adolescent and systems 
analysis as infantile. 

11. Controls are weak - especially in areas involving manual forms. Manage- 
ment is committed to blind trust in the loyally, honesty and ability of people. Planning 
and scheduling is largely based on fear and superstititon rather than scientific skill 
and requirements. 

12. Optimism pervades. Ideas are being formulated, exchanged, and tried. 

/ 

Projections for the Future 

1. Problems . The excessive demand for programmers today and the "sweat 
shop" environment resulting from long hours and pressure may birth new problems. 
There are faint rumblings of programming fraud. This could grow into a problem and 
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be joined with sabotage. More serious could be a mass influx of non-dedicated and 
non-professional programmers working beside experienced programmers who have 
programmed for 25 years, experienced 20 conversions, have not been promoted, and 
have lost enthusiasm. The result: "old burned-out programmers" corrupting and 
limiting the enthusiasm of youth. 

2 . Possibilities . There are many areas of promise ! Some national standards 
may come to pass. Some manufacturers may strive for compatability. Perhaps major 
software "break-throughs" are in store. Wired-in programs offer hope with the "com- 
piler in a box" concept. Scientific methods for planning and scheduling are possible. 
For example, if graphs could be constructed weighing such factors as program length, 
type, level of complexity, previous patches, needed changes and type of changes, age 
of program, etc. , it is conceivable that from the resulting graphs could be determined 
the desirability of complete reprogramming over program maintenance. Similar tools 
are possible for scheduling, evaluating, etc„ But they would have to be non-frightening 
and easy to use and accepted by managers. 

3. Rec ommendati ons . College students should be allowed past the in-out 
counter to get hands-on experience and to study operations. . .not for the purpose of 
programming, but to facilitate management and understanding. Programming courses 
should present documentation standards as an integral part of programming. Courses 
should provide contact with actual installations and real people. 

Users are neglecting college students as a promising source of programmers. 
The Co-op plan is outstanding in that students simultaneously receive schooling with 
professional practice. If these students are employed in pairs, one is always on the 
job. In six years, the company has two graduates with three years experience. Other 
students could be used part time or as part of course work. 

It is ironic that the possessors of the world’s most sophisticated information 
systems are themselves weak in the flow of information. First of all they must clearly 
express and demand what they want of the manufacturers , especially with respect to 
software. Secondly, a free exchange of ideas between non-competitive organizations 
would help solve problems and provide new ideas in programming management. The 
requirement is for a concerted, cooperative, and coordinated effort by responsible 
managements to place programming in a management perspective. Accomplishing this 
without sacrificing the creativity and productivity of the novice, professional, or 
virtuoso programmer is the challenge. 
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I. INTRODUCTION 



In order to assure that project requirements are met in a timely, economical, 

efficient and accurate manner, the following project policy and implementation pro- 
cedures are to be followed. 



n. PHILOSOPHY 

A, System Desigm 

The over-all system design and definition of a computer application is usually 
a complex task requiring a high level of logical thought and detailed planning. Such 
logical planning is performed more easily, more timely, and with greater sophisti- 
cation if more than one analyst is involved in the initial design. The early design 
phase of a product determines its ultimate quality. The most experienced computer 
professionals should be used during this phase, 

B, Programming 

hi computer programming, one hundred per cent accuracy is an absolute 
objective. All steps must be taken to assure that not one single error remains in the 
final product. Careful planning, coding and checking must be followed by test runs 
under all conceivable conditions before a program can be considered operational. 

C, Documentation 

The most efficient and sophisticated computer system application is useless 
without complete, easily understood documentation including system description, 
flow charts, program listings, data formats, output format descriptions and run in- 
structions, Such documentation is a necessity if someone other than one of the 
original program authors is to make the inevitable changes and modifications neces- 
sary to satisfy new or unanticipated requirements on the system. 

D, Operation 

An application is not completed until the system is operating under its "perma- 
nent” operating personnel. Training or orientation required by operating personnel 
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in order to use the system effectively must be provided. Proper staffing at the time of 
initial operations is essential to the success of any project. 



III. IMPLEMENTATION 

Implementation of the principals set forth in the previous section can be accom- 
plished according to the task outline set forth below. A schedule is established which 
estimates the time spent on each phase of the project. As the work progresses, the 
project leader must keep informed of the schedules and financial status. When each 
increment of 25 per cent of the estimated total project cost is reached, higher manage- 
ment and the project leader should review status and revise estimated completion time 
and cost. The work proceeds according to the following outline: 

1. Analysis of the subject systems requirements to identify all input 
data and establish the general format for necessary and desired 
reports . Establish the run frequency and distribution of such re- 
ports. 

2. Analysis of the present mode of operation to determine what changes 
should be made to the system to facilitate an automated approach. 

3. Design and documentation of the total system "in-the-large” includ- 
ing macro flow charts, relationship of individual modules and exist- 
ing library packages as well as complete descriptions and samples 
of all input and output data, 

4. The proposed system must be reviewed by the operations depart- 
ments, consultants, and systems designers to ensure that all require- 
ments have been met, that all data formats are acceptable and that 
the total system design is logically complete and sound. Modifications 
to take care of any discrepancies or desired features should be made 
at this time. This review should include refined cost analysis and 
updated time schedules. 

5. System programming, coding, and testing under the supervision of 
the project leader should ensure a high quality product. All work 
must be checked and re-checked including comparison of test run 



cases against known results. All documentation must be reviewed 
by an analyst, not a participating author, to determine that it is 
complete and readily understood. 

6. Management approval may be obtained after a staff consultant 

reviews the completed work package and certifies that it is ready 
for use. 

7. Delivery and installation of final equipment and software is super- 
vised by the project leader who arranges for any operating personnel 
training that may be necessaiy. All test cases should be re-run to 
ensure that the final operating system produces the same results 

as the test system. 

8. Before final acceptance, the entire system will be in operation for 

a period of time sufficient to identify faults or desired modifications. 



